​
Field Mapping Framework

Antei uses a centralized, schema-driven mapping system to standardize data across all integrations. This ensures that no matter where your data comes from — billing platforms, HRIS systems, or file uploads — it aligns with Antei’s internal structure.

​
Why Mapping Matters

  • Creates a unified data model across systems
  • Enables clean reporting, reconciliation, and filings
  • Reduces ambiguity around field interpretation
  • Ensures type-safe, jurisdiction-aware processing

​
Key Concepts

1

1. Internal Registry

Every entity in Antei (e.g. Transaction, Product, Contact, Invoice) has a field registry.
This includes:
  • Field name (contact_id, tax_rate, amount)
  • Data type (string, enum, date, etc.)
  • Validation rules (e.g. required, format)
  • Classification tags (e.g. sensitive, jurisdictional, calculated)
This registry forms the basis of mapping logic for integrations and manual imports.
2

2. Source-to-Target Mapping

For each integration (e.g. Stripe, Xero), a mapping configuration is defined:
  • Source fields → Antei registry fields
  • Includes type conversion and optional transformations
  • Handles nested structures and system-specific edge cases
📌 Example: stripe_customer.id → contact_id, xero_invoice.total → invoice_total_amount
3

3. Context-Aware Resolution

  • Mapping logic accounts for record context:
    → E.g. a contact can be a customer, vendor, or tax authority
  • Field roles adjust based on module (e.g. entity_id is optional for product uploads, required for transactions)
  • Some fields (like country, currency, taxability) drive jurisdiction-specific rules
4

4. Dynamic Metadata Storage

  • All mappings are traceable
  • Metadata such as source, extracted_id, and payload_origin are stored for each field
  • This enables validation rollback, re-mapping, and audit trail traceability
Example:
{
  "mapped_field": "invoice_total_amount",
  "source": "stripe_invoice.total",
  "extracted_id": "abc-123",
  "mapping_version": "v1.4"
}
5

5. Registry-Driven UI & Validation

  • The UI uses the field registry to dynamically generate mapping UIs and enforce constraints
  • Field descriptions, types, and tooltips are directly derived from the registry
  • Same rules are enforced for integrations, imports, and manual input

​
Supported Entity Types

Antei currently maps and processes the following core entities:
EntityDescription
TransactionsPurchases, refunds, and payments across platforms
ProductsTaxable goods/services with jurisdictional and taxability configurations
ContactsUnified representation of customers, vendors, tax authorities, and locations
InvoicesBilling and compliance documents mapped with product and contact references
Transaction OpsOperational breakdowns such as payment splits, refunds, and adjustments

​
Real-Time Updates

  • The mapping engine is dynamic and versioned
  • Changes to source platforms (e.g. new fields in QuickBooks) are patched at runtime
  • Registry can be extended for custom fields if required

​
Integration Coverage

Each supported integration (e.g. Stripe, QuickBooks, Zoho Books) has a dedicated mapping config. These are maintained and versioned internally and can be updated without code changes by Antei’s backend services.

​
Need Help?

For a specific mapping breakdown, visit the Integration Scope for each platform, or contact support@antei.com.